ECSのサービスディスカバリーが東京にやってきて、コンテナ間通信の実装が簡単になりました！
「別コンテナつくったでー。ほな、同じECSクラスタ内のコンテナ同士つないでみよっか… ってどないして繋げんねん？」
ECSのコンテナ間通信の実装を劇的に簡単にするサービスディスカバリーの機能が、つい先日、東京リージョンで利用可能となりました！
Amazon ECS Service Discovery がフランクフルト、ロンドン、東京、シドニー、シンガポールの各リージョンで利用可能に
コンテナ間通信を前提とするマイクロサービスのECS実装において、その通信制御をむっちゃ簡単に実現する素晴らしい機能なので、今までALBでコンテナ間通信頑張って実現していた人も、まずはこの機能一回試していただくことを強くオススメ致します。
この記事では、「そもそもECSのサービスディスカバリーってなんやねん」という解説から、ALBで実現していたときとの違い、運用上便利になった点、および実際の設定の様子をお届け致します。
ｻｰﾋﾞｽﾃﾞｨｽｶﾊﾞﾘｰ きたか…!! ( ﾟдﾟ) ｶﾞﾀｯ / ヾ ＿_L| /￣￣￣/＿ ＼/ /
ECSのサービスディスカバリーとは？
詳細は、下記AWS公式ブログを参照。
Amazon ECS サービスディスカバリ | Amazon Web Services ブログ
一言でいうと、「ECSクラスタ内で他のコンテナへアクセスするためのAレコード登録を, 自動的にECSとRoute 53にお願いできる」機能となります。
従来の他コンテナアクセス実現方法
インターネットフェーシングなフロントエンドコンテナと、バックエンドコンテナとの通信方法を例に見てみましょう。
この場合、フロントエンドコンテナからバックエンドコンテナへ通信するためによくやるのが、バックエンドコンテナの前に、インターナルなバックエンドALBを設置しておくことです。
ECSのバックエンドサービスとして、バックエンドコンテナを登録しておけば、オートスケールでコンテナが増減したときも自動的にALBにコンテナが紐づくので、フロント側からは、バックエンドALBに対して名前解決するだけで、バックエンドコンテナにアクセスできます。
Route53に登録するレコードはこんな感じ。フロントとバックの両方のALBを予め作成し、レコード登録しておきます。フロントALBはインターネットフェーシングなのでパブリックIPを、バックエンドALBはインターナルなALBなのでプライベートIPを、それぞれ返します。
| Name | Type | Value | 設定方法 |
|---|---|---|---|
| front.example.com | A（エイリアスレコード） | front-albのDNS | 事前作成 |
| back.example.com | A（エイリアスレコード） | back-albのDNS | 事前作成 |
これで、フロントコンテナからは、back.example.comを名前解決することで、バックエンドのコンテナにアクセスできるわけです。
ECSサービスディスカバリーを利用した他コンテナアクセス方法
ECSサービスディスカバリーを利用した他コンテナアクセス方法を、すっごい概念的に書くとこんな感じです。
前段の例と比べると、バックエンドALBが、Route 53の自動登録Aレコードに置き換わるイメージですね。
Route 53に登録されるレコード例。
| Name | Type | Value | 設定方法 |
|---|---|---|---|
| front.example.com | A | front-albのDNS | 事前作成 |
| back.example.com | A | back-container-1のプライベートIP | Auto Naming APIによる自動登録 |
| back.example.com | A | back-container-2のプライベートIP | Auto Naming APIによる自動登録 |
| back.example.com | A | back-container-3のプライベートIP | Auto Naming APIによる自動登録 |
つまりは、オートスケールやタスク数設定によるコンテナ増減に連動して、Route 53のレコードが自動的に書き換えられるということすね。
従来から存在したRoute 53のAuto Naming
実は弊社大瀧が書いた、下記記事に有るように、Route 53のAuto Naming APIを利用したサービスディスカバリー実装の機能自体はありました。
今回紹介する機能は、これをECSに拡張したものと言えます。
実際にECSサービスディスカバリーを設定してみる
前置きが長くなりましたが、実際にECSに登録する様子を見てみましょう。既に、既存のECSクラスターとタスク定義がある前提で解説していきます。
従来どおり、ECSのサービスを作成していきます。今回は起動タイプもFARGATE、タスクの数は3つで設定します。
ネットワーク構成に、「サービスの検出」の項目が増えています。
以下、各入力項目を解説していきます。
サービスの検出の統合の有効化
なにはなくとも、まずはこれにチェックをする必要があります。
名前空間名
VPCに紐づく名前空間を指定します。例えば、このコンテナに対して、back.example.comでアクセスしたい場合、名前空間名にはexample.comを指定します。
これにより、Route 53にexample.comという名前のプライベートゾーンが作成されます。
サービスの検出サービスの設定
このECSサービスに対する検出名を入力します。これは、作成するDNSレコードのプレフィックスとして使用されます。上の例だと、backを指定します。
ECSタスク状態の伝達の有効化
解説の通りですが、このフィールドを有効化しておくことで、異常なタスク（コンテナ）をRoute 53のレコードから削除する速度が早くなるらしいです。チェックしておくと良いでしょう。
サービスの検出のDNSレコード
Auto Naming APIで自動登録するレコードの種類をAレコード、SRVレコードから選択します。
名前解決時、通常のAレコードを利用するのであれば、そのままAレコードで登録します。
あとは、通常のECSサービスの指定と変わりません。サービス作成後、無事関連リソースが作成されればOKです。
注意事項1：サービスディスカバリー設定は変更不可
ECSサービスのロードバランサー設定も同じですが、ECSサービスに設定するサービスディスカバリーは、ECSサービスの作成後変更ができません。別の名前空間を割り当てたいときは、別の新サービスを作成する必要があります。
注意事項2：ヘルスチェック設定は、タスク定義のものを使用
ALB配下にタスクを紐づけている場合、コンテナへのヘルスチェックもALBのヘルスチェック機能を利用していた人が多いかと思いますが、今回の場合、ALBは使いません。
そのためヘルスチェックは、タスク定義の中で予め指定しておきます。こちらの記事を参考にしてください。
サービスディスカバリー指定して作成されたタスクとRoute 53レコードの確認
作成したサービスのタスク一覧を確認しましょう。無事、指定したタスク数（今回は3）が起動しております。
Route 53を確認すると、ホストゾーン一覧に、example.comという名前のプライベートゾーンが作成されています。
中を開くとこんな感じで、base.example.comに対して、サービス設定で指定したタスク数（今回は3）だけ、Aレコードが登録されています。やりますな！Aレコードが勝手に増える感覚はなかなか興味深い。
このプライベートIPアドレスは、もちろんECSサービスで起動された各タスクのIPアドレスと合致しています。あとは指定のドメイン名で他コンテナから、このコンテナにアクセスできるというわけでございます。
ALB利用時と比較した、ECSサービスディスカバリを利用時のメリット・デメリット
コンテナアクセスのために、ALBを利用していた場合と比べた、ECSサービスディスカバリのメリット・デメリットを書いてみます。
ECSサービスディスカバリのメリット
ALB全般の管理コストをもろもろ排除できます。ALBの設置料金や、構築、ALBに紐付けるRoute 53のエイリアスレコード、ALBに設定するセキュリティグループの管理など諸々を考慮外にできるメリットは大きいでしょう。
特に、ECSを開発、ステージング、本番環境で運用したり、マイクロサービス実装で1クラスタに多数のサービスがある場合などは、管理コスト削減の恩恵はでかいです。
ECSサービスディスカバリのデメリット
ALB（及びNLB）で提供している、L4/L7周辺の機能が利用できません。パスルーティングによるターゲットの変更や、認証機能や、固定レスポンスなどの機能も使えません。
とは言え、最初からヘルスチェックのみにALBを利用していたのであれば、ECSサービスディスカバリへの移行は、特に問題にならない場合が多いかと思います。
「いろんな管理コストが削減できて、柔軟性も高く、運用楽やでこりゃ」
雑に感想書くと、そんな感じです。
そもそも、マイクロサービスな環境で、新しい接続先を発見するためには、Consul by HashiCorp などの、サービスディスカバリの導入が必要でしたが、そのインフラをプロビジョニングして管理する手間や、コンテナへのエージェント登録など、追加の作業が必要でした。
今回のECSサービスディスカバリを活用すると、接続先の名前空間の情報のみを接続元に持たせておけば、あとは、ECSが名前空間へのコンテナの登録をヘルスチェック含めてすべて自動化してくれて、かつそれがマネージド・サービスのみで実現可能なので、管理運用、むっちゃ楽になります。
マイクロサービスのECS実装において、第一候補にあげるべき機能なので、同じようなシチュエーションで悩んでいるかたは、まずはこちらを試してみてはいかがでしょうか。
それでは、今日はこのへんで。濱田（@hamako9999）でした。
おまけ（今回の記事のきっかけになったツイート）
ぜひ ECS サービスディスカバリーを...！
— ポジティブな Tori (@toricls) 2018年9月4日
全ては、ここから始まりました。ポジティブな Tori(@toricls)さんさん、多謝！！
AWS公式参考リンク
AWSにおけるマイクロサービス実装について網羅的に解説されているドキュメントです。
サービスディスカバリについては、こちらに、その他様々なパターンの解説があります。
